The OPC UA Publish-Subscribe Client is a specialized client object providing access to PubSub information model in OPC UA.
Note that although the OPC UA PubSub exchanges the data using its own protocols and can stay on its own, the information model provides additional useful integration with OPC UA infrastructure. The information model for OPC UA PubSub is accessed using "normal" OPC UA Client-Server technologies. This means that the OPC UA Publish-Subscribe Client accesses data in some "live" OPC UA server that must be available at the time your program makes the operations. Additionally, the OPC UA Publish-Subscribe Client gives you access to OPC UA PubSub configuration data stored in files.
This specialized client object can be derived from IEasyUAClient Interface using the AsPublishSubscribeClient Extension Method, or it can be created standalone as EasyUAPublishSubscribeClient Component.
In order to access the PublishSubscribe element, which is at the top of the PubSub information model, use the GetPublishSubscribeElement Method. The PublishSubscribe element allows you to find out which transport profiles are supported by the publisher or subscriber associated with the server, using the SupportedTransportProfileUriStringSet Property.
The HasConfigurationModel Method determines whether the specified OPC UA server provides a PubSub configuration model. This allows you to make such test cleanly, without possibly causing an error (exception being thrown).
The "main" method of the OPC UA Publish-Subscribe client is the AccessReadOnlyConfiguration Method returns the IUAReadOnlyPubSubConfiguration Interface which provides read-only access to PubSub configuration provided by the specified server. If, instead of accessing the "live" configuration in the OPC server, you want to load the PubSub configuration from a specified file (in UABinary format), use the LoadReadOnlyConfiguration Method. The PubSub configuration interface then provides members described in Accessing OPC UA PubSub Configuration Model.
If your PubSub configuration is in the UABinary format, but not stored in a file, you can use the UAEncodedReadOnlyConfigurationLoader Property. It returns an instance of StreamLoader<TValue> Class which you can use to load the configuration from an array of bytes, a Stream, a managed resource, and so on.
For more functionality, and detailed information, see the Reference: IEasyUAPublishSubscribeClient Interface, EasyUAPublishSubscribeClient Class and IEasyUAPublishSubscribeClientExtension Class.
Some OPC UA servers offer the PubSub configuration in form of a node representing the OPC UA file object. The file contains the PubSub configuration in the UABinary file, same as it would appear in a regular file (file on disk). This can be the only way the OPC UA server offers the PubSub configuration (possibly because the server is a small embedded server), or it can be in addition to the standard way of providing the PubSub configuration (which involves many related OPC UA nodes in a complex mesh). Representing the PubSub configuration in this way is practical for many uses cases practical. It was a non-standard practice in OPC UA 1.04 (and appeared mainly in servers built with Unified Automation toolkits). It has been standardized in OPC UA 1.05, albeit with a different node used for the PubSub configuration file. OPC Data Client recognized both the standard node, and the node specific to Unified Automation toolkits.
OPC Data Client has ability to load such PubSub configuration and work with it. If you know that the PubSub configuration is stored in this way in the server, you can use the LoadReadOnlyConfigurationFromFileNode Method to load it. There is also the HasConfigurationFileNode Method to test whether the "well-known" node with PubSub configuration is present in the server.
For generic case (when you do not know how the PubSub configuration is stored in the server), we recommend using the AccessOrLoadReadOnlyConfiguration Method. This method can decide dynamically, based on the actual OPC UA server contents, which approach to use to provide the PubSub configuration interface to you. The method has an otional argument which you can use to control which method of accessing the PubSub configuration will be used. Note the possible differences in behavior between the PubSub configuration interfaces returned in each case, described further in this article.
Accessing a PubSub configuration that is "live" in the OPC UA server always gives you the current status of the configuration, at every moment you call some operation on the PubSub configuration interface. This may be a good thing (if you are interested in up-to-date state), but also a bad thing (because OPC UA does not provide transactional access to the PubSub configuration, the information may change while you are working with different parts of it, and your code needs to be able to deal with it). Accessing a "live" PubSub configuration is generally slow (each operation requires one or more OPC UA service calls), and it may fail at any time (any operation may return an error caused by inability to perform the intended OPC UA service on the server).
In contrast, when you load the PubSub configuration from a file (or OPC UA file node in the server), it represents a one-time snapshot that does not change by itself. It resides in memory, and accessing it is fast. If used correctly, it also generally does not return any errors.
For easy set up, the examples provided here access OPC UA PubSub configuration data stored in a pre-made binary configuration file. The same principle can, however, be used to access configuration data provided by an OPC server. There are commented statements in the examples that show how to do it.
The example below starts at the "root" of the PubSub configuration, and first obtains names of all PubSub connections available (they are at the 1st level). For each PubSub connection, given its name, it obtains names of writer groups configured on that PubSub connection (they are at the 2nd level). And, for each such writer group, given its name, it obtains names of all dataset writers configured on that writer group (they are at the 3rd level). Besides the PubSub object names, the commented parts also show how to obtain more detailed information about each PubSub object.
The example below uses the ListAllPublishedDataSetNames Method to retrieve all published dataset from the PubSub configuration. The published datasets are actually organized in the PubSub configuration using a hierarchical structure of dataset folders. The word "all" in the method name denotes that the method will truly return all published datasets in the configuration, not just those at the "root" of the dataset folder structure, or in any specified dataset folder. The method will act recursively in the dataset folder structure, if needed. There are also methods that allow you to work with contents of individual dataset folders. Note that the published dataset names are unique across the PubSub configuration as a whole (regardless of their location in the dataset folder structure), and therefore a published dataset name is sufficient to identify the published dataset, and the dataset folder path is not strictly necessary.